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DETAILED ACTION 

1. A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 
CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible 
for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been 
timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 
1.1 14. Applicant's submission filed on November 24, 2006 has been entered. 



Claim Rejections - 35 USC § 103 



2. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all obviousness 
rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 



Bradshaw et al in view of Cheng et al. 

3. Claims 1, 4-5, 8-9, 12-13, 16-17, 20-21, 24, and 33-35 are rejected under 35 U.S.C. 103(a) as 
being unpatentable over Bradshaw et al. (USP 6,674,731) in view of Cheng et al. (USP 
6,040,851). 
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4. With regard to claims 1, 9, and 17, Bradshaw et al. discloses the transmission of TCP/IP data 
over a satellite link from a hub station to a plurality of remote terminal units [Abstract]. 
Bradshaw et al. further teaches user terminals [col. 4, lines 58-61] (hosts) connected to remote 
units [col. 4, lines 65-67] (terminal unit). The remote unit contains a receiver [col. 4, lines 14-15] 
and a transmitter [Fig. 8] for two-way communication. Bradshaw et al. also teaches the hub use 
of DVB format data frames [col. 3, lines 47-49]. The receiver must contain a MAC to DVB 
converter [col. 12, lines 38-40] to conform to DVB protocol format that is supported by the hub 
[col. 3, line 49]. Bradshaw et al. also teaches an RF receiver coupled to an antenna to permit 
exchange of data between the remote terminal and the satellite [Fig. 10]. A burst demodulator 
must be present in the RF receiver for demodulating the signal over the satellite link due to the 
nature of satellite communications. The data frame conforms with the DVB protocol format (i.e., 
the return channel frame format) [col. 3, line 49]. The hub station [Fig. 2, 104] is shown with 
the antenna and the RF transmitter/receiver. Thus, these elements are interpreted as containing 
the satellite-to-hub interface. Bradshaw et al. fiirther discloses that the hub is connected to an 
external packet switched network [Fig. 2, element 24; col. 4, lines 25-29], which, in this case, is 
the internet. The hub must necessarily be able to convert the protocol data frames received from 
the satellite into requests to/from content servers [col. 5, lines 13-17]. Bradshaw et al. also 
teaches a multi-layer protocol interface for the hub-to-terminal interface as the TCP/IP data is 
encapsulated into a MAC data frame [col. 7, lines 62-63] and because the TCP/IP frames are also 
formatted within the DVB frame [coL 8, lines 47-51]. 

Bradshaw et al. fails to specifically disclose the transmission of data bursts from the 
terminal to the host via a direct USB connection. Bradshaw et al. discloses that the connection 
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between the remote unit 108 A (terminal) and the user terminal 1 18A (host) is a LAN 116 [Fig. 
2]. Bradshaw et al. can use a standardized bus (e.g., the IEEE 802.6 DQDB) for conveying 
bursty video, which also has the advantage of improved performance characteristics [see 
generally, coL 3, lines 65-67]. Thus, the remote unit 108 A (terminal) in Bradshaw et al. receives 
the wireless signals from sateUite 106 and transports them to the user terminal 1 18A host via a 
LAN 116 [Fig. 2], A LAN involves much more complexity in connecting devices, such as the 
remote unit 108 A (terminal), to multiple user terminals 1 18A (hosts) [See Id.]. Furthermore, a 
remote unit 108 A (terminal) requires an interface and a driver in order to condition the signal and 
provide the physical interface to the LAN [coL 14, lines 15-23]. LAN 116 allows remote unit 
108A (terminal) to transport information in multiple formats/standards to those multiple user 
terminals 1 18A (hosts), which are connected to LAN 116. It is well known to those skilled in the 
art to use a direct connection between a terminal and host, instead of a LAN, because such a 
connection reduces the complexity of communicating over a LAN and allows more direct and 
efficient communications between the two devices. Moreover, it is also well known to those of 
ordinary skill in the art that there must be a functional interface between a receiver and 
transmitter (or transceiver) such that the transmitter receives data from the functional interface 
for transmission. 

Cheng et al. (USP 6,040,851) discloses a set-top box along with a receiver sub-system 
that integrates network-dependent functions into a digital interface conditional access module 
(DICAM) (host interface) which then can implement bursty video [MPEG 1, 2, or 3, col. 6, line 
25] from a variety of sources (to include satellite dishes and cable) and then implement them on 
a personal computer (host) to receive the data [Abstract; col. 1, lines 11-33]. Cheng et al. uses 
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the combination of a set-top universal box (STUB) (terminal) and the DICAM (host interface) to 
separate out the network-dependent and network-independent streams and functions [Figs. 3-5; 
coL 2, lines 8-17]. Thus, Cheng et al.'s STUB/DICAM [Figs. 3-5] receives satellite input 
signals [col. 6, line 16] and outputs the data/streams via a direct connection such as a universal 
serial bus (USB) [col. 6, lines 20-26]. A USB bus specifically supports (common) bursty video 
traffic. Bradshaw et al. and Cheng et al. both involve the transmission and reception of data over 
a wireless communication channel [both receive satelhte signals]. Moreover, both Bradshaw et 
al. and Cheng et al. disclose integrated services, specifically, transmitting the received data to a 
user terminal [user terminal 1 18A in Bradshaw et al. and a PC in Cheng et al.]. Thus, it would 
have been obvious to one of ordinary skill in the art at the time of the invention to have used the 
received satellite communications of Bradshaw et al. with the less-complex and directly- 
connected USB bus disclosed in Cheng et al. to connect the remote unit 108 A (terminal) and the 
user terminal 1 18A (host) because integrated services require interoperability between the 
receipt, and use, of bursty video data transmissions which contribute to improved performance 
characteristics. 

5. With regard to claims 4, 12, and 20, Bradshaw et al. discloses all teaches that MPEG format 
data is packaged into DVB protocol format [col. 2, lines 66-67], and TCP/IP data is encapsulated 
into an Ethernet MAC data fi-ame [col. 7, lines 62-63], that is, multi-layer protocol with support 
for DVB. 
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6. With regard to claim 5, Bradshaw et al. discloses that the data exchanged over the sateUite 
link is TCP/IP [col. 3, lines 37-39]. 

7. With regard to claims 8, 16, and 24, Bradshaw et al. discloses that the packet-switched 
network is the internet [Fig. 2, element 24]. 

8. With regard to claims 13 and 21, Bradshaw et al. discloses IP [col. 7, lines 62-63], an lETF- 
standardized protocol used for interfacing receiver and transmitter units, as well as for 
transmitting data. 

9. With regard to claims 33-35, neither Bradshaw et al. nor Cheng et al. specifically disclose 
using USB super frames to send data bursts to the host. Cheng et al. discloses a USB serial 
interface, which can handle bursty video and uses USB frames. It is well known to those skilled 
in the art that USB super firames can be used by devices sending video data (and other 
isochronous applications) when (a) there are large amounts of data to be sent; and (b) the device 
can reserve enough time slots to send the super frame [wherein problems with USB bus cycles 
and bandwidth can arise when the device has to contend with other devices on the same USB 
bus]. Since the combination of Bradshaw et al. and Cheng et al. teaches the less-complex and 
directly-connected USB bus between remote unit 108 A (terminal) and user terminal 1 18A (host), 
as noted above, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to have used USB super frames to send large bursts of video data between remote unit 
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108 A (terminal) and user terminal 1 18A (host) because there would be no other device to 
contend with for the USB bus's cycle or bandwidth. 



Bradshaw et aL in view of Cheng et aL further in view of Birdwell et at. 



10. Claims 6, 14, and 22 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Bradshaw et al. in view of Cheng et al. as applied to claims 1, 9, and 17 above, and further in 
view of Birdwell et al. (US Patent Publication 2001/0024435). 

11. With regard to claims 6, 14, and 22, Bradshaw et al. does not specifically disclose little and 
big endian data formats. However, Birdwell et al. discloses endian formats for IP packets 
transmitted over a satellite link [paragraph 0058]. Bradshaw et al. requires the determination of 
the beginning, the end, the LSB, and/or the MSB of the transmitted data frames in order to 
process the data frames. Endian formats aid in determining whether the first byte in the 
transmitted frames is the LSB or MSB. Thus, it would have been obvious to one of ordinary 
skill in the art at the time of the invention to have used the teachings of Bradshaw et al. in 
processing of transmitted data frames to have used the endian formats to aid in determining the 
LSB and MSB so that data alignment can be achieved at the receiver for either synchronization 
or CRC calculations. 
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Bradshaw et aL in view of Cheng et al further in view of Jorgenson et at. 

12. Claims 7, 15, and 23 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Bradshaw et al. in view of Cheng et al. as applied to claims 1, 9, and 17 above, and further in 
view of Jorgenson et al. (USP 6,680,922). 

13. With regard to claims 7, 15, and 23, Bradshaw et al. does not specifically disclose IGD 
packets. However, Jorgenson discloses UDP for transmission of packets over a wireless link 
[col. 12, lines 46-48]. IGD packets are formed from UDP packets. Therefore, it is obvious to 
those of ordinary skill in the art that UDP datagrams convey useful information parameters about 
the wireless link including the return channel ED and loading information. Moreover, UDP/IP 
packets encapsulate multiple data types, including IGD packets. 

Bradshaw et aL in view of Cheng et al further in view of Dillon et aL 

14. Claims 25, 28, 29, and 32 are rejected under 35 U.S.C. 103(a) as being unpatentable over 
Bradshaw et al. in view of Cheng et al. and further in view of Dillon et al. (USP 5,995,725). 

15. With regard to claim 25, Bradshaw et al. discloses the transmission of TCP/IP data over a 
satellite link from a hub station to a plurality of remote terminal units [Abstract]. Bradshaw et 
al. further teaches user terminals [col. 4, lines 58-61] (hosts) connected to remote units [coL 4, 
lines 65-67] (terminal unit). The remote unit contains a receiver [col. 4, lines 14-15] and a 
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transmitter [Fig. 8] for two-way communication. Bradshaw et al. also teaches the hub use of 
DVB format data frames [col. 3, lines 47-49]. The receiver must contains a MAC to DVB 
converter [col. 12, lines 38-40] to conform to DVB protocol format that is supported by the hub 
[col. 3, line 49]. Bradshaw et al. also teaches an RF receiver coupled to an antenna to permit 
exchange of data between the remote terminal and the satellite [Fig. 10]. A burst demodulator 
must be present in the RF receiver for demodulating the signal over the satellite link due to the 
nature of satellite communications. The data frame conforms with the DVB protocol format (i.e., 
the retum channel frame format) [col. 3, line 49]. The hub station [Fig. 2, 104] is shown with 
the antenna and the RF transmitter/receiver. Thus, these elements are interpreted as containing 
the satellite-to-hub interface. Bradshaw et al. further discloses that the hub is connected to an 
external packet switched network [Fig. 2, element 24; col. 4, lines 25-29], which, in this case, is 
the intemet. The hub must necessarily be able to convert the protocol data frames received from 
the satellite into requests to/from content servers [col. 5, lines 13-17]. Bradshaw et al. also 
teaches a multi-layer protocol interface for the hub-to-terminal interface as the TCP/IP data is 
encapsulated into a MAC data frame [col. 7, lines 62-63] and because the TCP/IP frames are also 
formatted within the DVB frame [col. 8, lines 47-51] 

Bradshaw et al. fails to specifically disclose the transmission of data bursts from the 
terminal to the host via a direct USB connection. Bradshaw et al. discloses that the connection 
between the remote unit 108 A (terminal) and the user terminal 11 8A (host) is a LAN 1 16 [Fig. 
2]. Bradshaw et al. can use a standardized bus (e.g., the IEEE 802.6 DQDB) for conveying 
bursty video, which also has the advantage of improved performance characteristics [see 
generally, col. 3, lines 65-67]. Thus, the remote unit 108 A (terminal) in Bradshaw et al. receives 
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the wireless signals from satellite 106 and transports them to the user terminal 1 18A host via a 
LAN 1 16 [Fig. 2]. A LAN involves much more complexity in connecting devices, such as the 
remote unit 108 A (terminal), to multiple user terminals 1 18A (hosts) [See Id.], Furthermore, a 
remote unit 108 A (terminal) requires an interface and a driver in order to condition the signal and 
provide the physical interface to the LAN [col. 14, lines 15-23]. LAN 1 16 allows remote unit 
108 A (terminal) to transport information in multiple formats/standards to those multiple user 
terminals 1 18A (hosts), which are connected to LAN 116. It is well known to those skilled in the 
art to use a direct connection between a terminal and host, instead of a LAN, because such a 
connection reduces the complexity of communicating over a LAN and allows more direct and 
efficient communications between the two devices. Moreover, it is also well known to those of 
ordinary skill in the art that there must be a functional interface between a receiver and 
transmitter (or transceiver) such that the transmitter receives data from the functional interface 
for transmission. 

Cheng et al. (USP 6,040,851) discloses a set-top box along with a receiver sub-system 
that integrates network-dependent functions into a digital interface conditional access module 
(DICAM) (host interface) which then can implement bursty video [MPEG 1, 2, or 3, col. 6, line 
25] from a variety of sources (to include satellite dishes and cable) and then implement them on 
a personal computer (host) to receive the data [Abstract; col. 1, lines 11-33]. Cheng et al. uses 
the combination of a set-top universal box (STUB) (terminal) and the DICAM (host interface) to 
separate out the network-dependent and network-independent streams and functions [Figs. 3-5; 
col. 2, lines 8-17]. Thus, Cheng et al.'s STUB/DICAM [Figs. 3-5] receives satellite input 
signals [col. 6, line 16] and outputs the data/streams via a direct connection such as a universal 
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serial bus (USB) [col. 6, lines 20-26], A USB bus specifically supports (common) bursty video 
traffic. Bradshaw et al. and Cheng et al, both involve the transmission and reception of data over 
a wireless communication channel [both receive satellite signals]. Moreover, both Bradshaw et 
al. and Cheng et al. disclose integrated services, specifically, transmitting the received data to a 
user terminal [user terminal 1 18A in Bradshaw et al. and a PC in Cheng et al.]. Thus, it would 
have been obvious to one of ordinary skill in the art at the time of the invention to have used the 
received satellite communications of Bradshaw et al. with the less-complex and directly- 
connected USB bus disclosed in Cheng et al. to connect the remote unit 108 A (terminal) and the 
user terminal 1 18A (host) because integrated services require interoperability between the 
receipt, and use, of bursty video data transmissions which contribute to improved performance 
characteristics. 

16. With regard to claim 28, Bradshaw et al. does not specifically disclose processors executing 
instructions to configure one or more of the interfaces. However, Dillon et al. discloses a 
satellite-based internet access system. The system of Dillon et al. contains several elements, 
including an application server and interface, hybrid gateway, and satellite gateway. A 
processor, executing instructions stored in memory may configure the gateway and the interfaces 
[col. 3, lines 62-65]. It is obvious to one of ordinary skill in the art that the same processor 
operating under instructions stored in memory, can also configure other/multiple interfaces. 
Thus, it would have been obvious to one of ordinary skill in the art at the time of the invention to 
combine the two-way satellite communications system of Bradshaw et al. to include the stored 
instructions executing in the processors of Dillon et al. because integrated services require 
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interoperability between transmissions which contribute to improved performance characteristics 
as well as universal compatibility as well as flexibility. 

17. With regard to claim 29, Bradshaw et al. discloses IP [coL 7, lines 62-63], an lETF- 
standardized protocol used for interfacing receiver and transmitter units, as well as for 
transmitting data. 

18. With regard to claim 32, Bradshaw et al. discloses that the packet-switched network is the 
internet [Fig, 2, element 24]. 

19. With regard to claim 36, neither Bradshaw et al. nor Cheng et al. specifically disclose using 
USB super frames to send data bursts to the host. Cheng et al. discloses a USB serial interface, 
which can handle bursty video and uses USB frames. It is well known to those skilled in the art 
that USB super frames can be used by devices sending video data (and other isochronous 
applications) when (a) there are large amounts of data to be sent; and (b) the device can reserve 
enough time slots to send the super firame [wherein problems with USB bus cycles and 
bandwidth can arise when the device has to contend with other devices on the same USB bus]. 
Since the combination of Bradshaw et al. and Cheng et al. teaches the less-complex and directly- 
connected USB bus between remote unit 108 A (terminal) and user terminal 1 18A (host), as 
noted above, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to have used USB super frames to send large bursts of video data between remote unit 
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108 A (terminal) and user terminal 1 18A (host) because there would be no other device to 
contend with for the USB bus's cycle or bandwidth. 

Bradshaw et al in view of Cheng et aL and Dillon et aL, further in view of Birdwell et aL 

20. Claim 30 is rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et al, 
Cheng et al., and Dillon et al. as applied to claim 25 above, and further in view of Birdwell et al. 

21. With regard to claim 30, Bradshaw et al. does not specifically disclose little and big endian 
data formats. However, Birdwell et al. discloses endian formats for IP packets transmitted over a 
satellite link [paragraph 0058]. Bradshaw et al. requires the determination of the beginning, the 
end, the LSB, and/or the MSB of the transmitted data frames in order to process the data frames. 
Endian formats aid in determining whether the first bytes in the transmitted frames are the LSB 
or MSB. Thus, it would have been obvious to one of ordinary skill in the art at the time of the 
invention to have used the teachings of Bradshaw et al. in processing of transmitted data frames 
to have used the endian formats to aid in determining the LSB and MSB so that data alignment 
can be achieved at the receiver for either synchronization or CRC calculations. 
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Bradshaw et aL in view of Cheng et at. and Dillon et aL, 
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further in view of Jorgenson et aL 



22. Claim 31 is rejected under 35 U.S.C. 103(a) as being unpatentable over Bradshaw et al. in 
view of Cheng et al. and Dillon et al. as applied to claim 25 above, and further in view of 
Jorgenson et al. (USP 6,680,922). 

23. With regard to claim 31, Bradshaw et al. does not specifically disclose IGD packets. 
However, Jorgenson discloses UDP for transmission of packets over a wireless link [col. 12, 
lines 46-48]. IGD packets are formed from UDP packets. Therefore, it is obvious to those of 
ordinary skill in the art that UDP datagrams convey useful information parameters about the 
wireless link including the return channel ID and loading information. Moreover, UDP/IP 
packets encapsulate muhiple data types, including IGD packets. 

Response to Arguments 

24. Applicant's arguments with respect to claims 1, 4-5, 8-9, 12-13, 16-17, 20-21, 24, and 33-35 
have been considered but are moot in view of the new ground(s) of rejection. 

25. Applicant's representative argues that Bradshaw et al. fails to disclose, apparently, an 
interface that permits data exchange between a receiving unit and a transmitting unit in a single 
terminal [Applicant's Response dated November 24, 2006, page 11, lines 3-11]. As explained 
in the rejections above, Bradshaw et al. discloses, teaches, and/or suggests several interfaces. 
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Specifically, Bradshaw et al. is interpreted as encompassing the interface that receives data from 
the interface and permits translation of data from one protocol to another [i.e., terminal 
interface]. 



26. Any inquiry concerning this communication or earlier communications from the examiner 
should be directed to Mark A. Mais whose telephone number is 572-272-3138. The examiner 
can normally be reached on M-Th 5am-4pm. 

27. If attempts to reach the examiner by telephone are unsuccessful, the examiner's supervisor, 
Seema Rao can be reached on 571-272-3174. The fax phone number for the organization where 
this application or proceeding is assigned is 571-273-8300. 

28. hiformation regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. / 



Conclusion 
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